The average size and complexity of content such as web pages have constantly been growing. For instance, an average web page has over 100 objects and is approximately 1,200 Kbyte in size today. The rendering of such a voluminous web page is a resource consuming task causing heavy load on the user equipment (UE hereinafter). Moreover, the load times for such web pages can amount to 5 seconds and more (e.g., with a 10 Mbps connection and a modern Personal Computer, PC). It is evident that such load times significantly reduce the Quality of Experience (QoE) from a user perspective (e.g., in terms of start of web page rendering). As such, the web page load time is a key performance indicator (KPI) for user QoE, and thus many approaches aim to reduce this KPI.
The two main factors that a web page load time depends on is the CPU performance of the UE (in terms of computational time) and network capacity (in terms of load time). The potential of the enhancing either of these two factors has already been analyzed. In this regard, the following gains have been estimated: a) when computational time is reduced to zero but the network load time remains unchanged, the web page load time is reduced by 20%; conversely, b) when the network load time is reduced to one fourth, but the computational time remains unchanged, the page load time is reduced by 45%.
With an eye to a satisfactory QoE, a start rendering time ranging from 1 to 2 seconds has been recommended. This is because giving the user visual feedback that something is happening shows the user that the UE is in fact responsive. The user can plan, anticipate and adjust himself/herself to consistent response times when browsing web pages. The user can also already start browsing when most of the information of the web page (i.e., the textual content) has been rendered, while large pictures are still downloaded in the background.
The start rendering time is typically composed of a Time to First Byte (TTFB) connect time, a server response time, a time for processing objects in the head of the page, a time for initial page parsing and a time for rendering. Optimizing the start rendering time is a matter of optimizing one or more of these delay components.
There are several possible aspects to overcome unnecessarily long start rendering times. One aspect pertains to new protocols to improve Roundtrip Time (RTT) and introduces prioritization of objects (e.g., SPeeDY, SPDY, and Quick User Datagram Protocol, UDP, Internet Connections, QUIC). Another aspect focuses on server-side optimization of the content by modules like mod_pagespeed. Moreover, a still further aspect relates to client side methods like caching, prefetching and preloading.
Today, most operators apply so called “middle boxes” with Deep Packet Inspection (DPI) to introduce traffic differentiation in the network for Internet traffic and to thus enhance user QoE. However, commonly applied end-to-end encryption (as implemented, e.g., in SPDY and QUIC) prevents the support of any kind of QoE enhancement on the last hop of such traffic.
In the example of a wireless communication scenario, end-to-end encryption thus makes it impossible for any intermediate component to be aware of the objects that are transferred through the radio access network. Thus, current DPI techniques cannot support the radio access network with the necessary information, and middle boxes are banned out from the route by design of, for example, QUIC.
Over-the-top (OTT) application providers are thus introducing other ways to improve QoE. For instance, to improve web rendering time, prioritization of web requests in requests and responses in the QUIC protocol has been introduced. QUIC uses end-to-end encryption (which is expected for most traffic in the future) and multiplexing, so supporting per flow prioritization requested by the application in the network is a challenging problem although it would enhance end-user QoE even further.